% ----------------------------------------------------------------------- %
% Arquivo: cap3.tex
% ----------------------------------------------------------------------- %
\chapter{O modelo RM Diffserv e a Sinalização NSIS}
\label{c_cap3}

A utilização de sinalização de fluxo em um domínio de rede induz o uso de uma entidade que interprete esta sinalização e a especificação do fluxo que a sinalização carrega. Esta entidade deve gerenciar a rede e ser capaz de conhecer seu comportamento. Dois modelos de gerenciadores de recursos conhecido para trabalhar com o NSIS, o RMF (Resource Management Function), próprio do NSIS, para reserva por fluxo e o RMD (Resource Management in Diffserv) para reserva por classe de fluxo são exemplos desta entidade.

O RM DiffServ introduz reserva dinâmicas e de controle para a admissão de fluxo na arquitetura DiffServ. O RMD complementa a arquitetura Diffserv, aplicando classificação dinâmica por fluxo e controle de funções das bordas de um domínio Diffserv utilizando simplesmeste classe de tráfego (por DSCP), funções de admissão de controle nos nós do núcleo do domínio DiffServ.

O modelo RMD QoS permite entidades que são externas ao domínio DiffServ sinalizar pedidos de reserva nos nós de borda do domínio. No nó de entrada do domínio o RM DiffServ pode classificar a sessão de fluxos de tráfego em classes e sinaliza a solicitação de pedido de recursos para a classe correspondente ao longo do caminho, no interior do domínio até o nó de saída para cada sessão de fluxo.

O modelo RMD QoS (RMD-QOSM) faz uso de mensagen definidas do NSIS, mas acrescentando um objeto específico RMD-QSpec, que é a especificação do fluxo da requisição de QoS. O NSIS sinaliza esta especificação para os nós das bordas do domínio.

O protocolo QoS-NSLP (NSLP - NSIS Signaling Layer Protocol) estabelece e mantém estados nos nós, ao longo do caminho de um fluxo de dados, com o objetivo de fornecer encaminhamento dos recursos para esse fluxo na rede. No entanto, para este recurso ser provisionado o NSIS especifica o fluxo atráves do QSPEC (QoS Specification). O RMD-QSpec, que é utilizado para fornecer de forma dinâmica a gestão de recursos dentro do domínio Diffserv.

Este trabalho irá discorrer mais profundamente sobre a sinalização de fluxo de tráfego, utilizando o protocolo de sinalização NSIS. Contudo, para que a rede ofereça e garanta priorização de tráfego o NSIS deve trabalhar em conjunto com uma entidade que gerencia a rede baseado em sua estrutura.

%-------------------------------------%

% ----------------------------------------------------------------------- %
% Arquivo: rmdiffserv.tex
% ----------------------------------------------------------------------- %

\section{RM DiffServ}
\label{c_cap_rmdiffserv}

O gerenciamento entre a sinalização e alocação de recursos no domínio DiffServ é o modelo proposto pelo Resource Manager DiffServ (RMD – RM DiffServ). O modelo RM Diffserv é uma proposição para o gerenciamento dinâmico de domínios DiffServ.

O RMD tem duas funções básicas para controlar o tráfego em um domínio DiffServ: admissão que prevê o controlo dos fluxos que entram na rede e que tem um algoritmo que termine o montante exigido de fluxos em caso de congestionamento causado por falhas (por exemplo, link ou roteador) no interior um domínio DiffServ. A admissão controle dentro do domínio pode ser tanto de medição como baseado em reserva. A base do mecanismo de sinalizaçãondo é descrito para diferentes cenários e o desempenho esperado do protocolo é discutido.

O modelo RM DiffServ atualmente é um Draft (rascunho) da IETF\footnote{Internet Engineering Task Force} de \textit{RMD-QOSM - The Resource Management in Diffserv QOS Model} que descreve o conceito do protocolo NSIS (Next Steps In Signaling) sobre o domínio de RM DiffServ (Resource Management DiffServ).
Este modelo basicamente provê um gerenciamento dos recursos de um fluxo entrante em um nó de borda e requisita recursos para este fluxo no nó de saída.

O Draft da IETF especifica modelos de trabalho com o NSIS aliado com o gerenciamento do RMD. Basicamente, especifica o RMD-QOSM (NSIS QoS Model for RMD networks) e as especificações de fluxo (QSPEC) para o modelo RMD. Este modelo é utilizado para sinalização fim-a-fim em uma rede IP, para prover sinalização de QoS em redes com RM DiffServ.

O DiffServ é uma arquitetura que não especifica como os dipositivos de saída reservaram recursos ou disponibilidade de recursos da rede, porém, o DiffServ provê uma arquitetura escalar. Por conta disto, o RM DiffServ consegue prevê um modelo de gerenciamento escalar, onde os estados por fluxo não são armazenados e sim a especificação da sinalização.

Dois modelos de aplicações do Resource Management DiffServ podem ser descritos para o controle de admissão de tráfego: baseado em reserva e baseado em medição. 
No método baseado em reserva, cada nó mantém apenas um estado por classe de tráfego. Os recursos são armazenados dinamicamente em todos os nós, por onde o tráfego passa, conforme requisitado.
O método baseado em medição é um algorítmo que continuamente mede os níveis de tráfego e a atual disponibilidade de recursos e admite os recursos se a especificação esta dentro da disponibilidade do nó.

RMD é uma técnica para a inclusão de controle de admissão em função de serviços diferenciados (DiffSserv). O modelo permite que dispositivos externos à rede sinalizar pedidos de reserva na borda de um domínio RMD. Estes classificam o tráfego em classes de fluxos e sinalizam a solicitação de pedido de recursos para a classe correspondente ao longo do caminho até a borda do domínio. O nó de saída reconstitui o pedido inicial e continua sua transmissão de dados ao longo do caminho para o destino final. Além disso, RMD define funções de notificação para indicar sobrecarga de situações dentro do domínio para os nós de borda.

Internamente ao domínio RMD, o RMD-QOSM juntamente com QoS-NSLP define um modelo de sinalização escalável por fluxo em que os estados não são armazenadas no Interior, mas nos nós do domínio onde a sinalização é realizada.

Em RMD, escalabilidade é alcançada por uma separação de classes de reserva, mecanismo utilizado na borda de um nó DiffServ, para um mecanismo muito mais simples de reserva necessário nos nós do interior do domínio. Tipicamente, assume-se que os nós de borda suportam estado de QoS por fluxo, a fim de fornecer garantias QoS para cada fluxo. O Interior do domínio utilzia um agregado de estado de reserva por classe de tráfego. Desta forma, é possível lidar com grandes números de fluxos no nós do interior do domínio.

\subsubsection{RMD-QOSM}
O QOSM é o como o gerenciador de QoS do domínio RMD. O RMD-QOSM é capaz de tanto modelar reservas, como dar suporte a sessões intra domínio, que podem ser por fluxo ou por agregado. Em sessões intra-domínio por fluxo, o estado do fluxo é mantido fim a fim. No caso de sessões por agregado, o estado é armazenado de um para muitos fluxos, para o mesmo nó.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.7]{figs/qosm_stateless.png}
 \caption{Modelo do protocolo}
 \label{fig:qosm_stateless}
\end{figure}

O modelo do protocolo RMD-QOSM é mostrado na Figura \ref{fig:qosm_stateless}. A figura mostra que os nós QNI e QNR, não fazem parte da rede RMD, os nós QNE Ingress/Egress do RMD domínio e os nós QNE que são nós do interior do domínio.(QNE Interior).

\begin{itemize}
 \item QNE: QoS NSIS Entity, nó intermediário de apoio ao QoS NSLP.
 \item QNI: QoS NSIS Initiator, nó que inicia a sinalização do QoS NSLP.
 \item QNR: QoS NSIS Receiver, nó onde a sinalização do QoS NSLP termina.
\end{itemize}

Todos nós do domínio RMD são geralmente nós conhecidos. Os nós de borda (Edge) armazenan e mantem os estados na camada de transporte e de aplicação (QoS-NTLP e NSLP), portanto, são nós stateful. O nós do interior do domínio, são conhecidos como stateless.
%-----------------------------%

% ----------------------------------------------------------------------- %
% Arquivo: nsis.tex
% ----------------------------------------------------------------------- %

\section{O protocolo NSIS}
\label{c_cap_nsis}

O NSIS (Next Steps in Signaling) é um protocolo de sinalização de fluxo de dados sobre redes IP. A sinalização é feita interagindo com os nós ao longo do caminho, sendo independente de roteamento e é utilizada para reservar banda ao longo do caminho.

O protocolo de sinalização NSIS, pode-se dizer, é um sucessor ao protocolo RSVP. Algumas diferenças entre o RSVP e o NSIS é que o protocoloca NSIS pode ser utilizado para diferentes necessidades, sem exigir uma completa implantação fim a fim. O NSIS, não necessariamente precisa garantir o estado em todos os nós, por este motivo, permitindo ser utilizado em domínios DiffServ. Além disto, o NSIS pode efetuar reserva de trás para frente. Neste modelo, o NSIS recebe um fluxo em um nó, sinaliza para frente uma query, que verifica o nó e o provisionamento de recursos até o nó destino. O nó de destino ecaminha então uma mensagem de reserva. Detalhes de funcionamento deste modelo em \ref{cenario_ambiente2}.

O protocolo NSIS é destinado a fins mais do que apenas reserva de recursos. Como é dividido basicamente em duas camadas, a camada de tranporte (NTLP) e de aplicação (NSLP). A camada de transporte GIST, é genérica e conta com diversos de grupos de trabalho de desenvolvedores.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.6]{figs/nsis_layers.png}
 \caption{Modelo Camada NSIS}
 \label{fig:cap_nsis_layers}
\end{figure}

A diferenciação de camadas, requer que as informações do tráfego sejam passadas para a camada superior, de aplicação, para verificação de estado. Na camada de aplicação, as informações são analisadas e tratadas. Em geral, nos nós do interior do domínio, é feita apenas o reconhecimento da sessão, modo stateless. Ja nos nós de borda, em geral, é verificado estado e a sessão conforme especificação de QoS.

Este conceito de 'sessão' é diferente do RSVP, que define uma sessão como um fluxo com um destino de endereço específico, na camada de tranporte. O uso de 'sessão' no NSIS é um conceito de protocolo de camada superior \cite{RFC4080}, que mantém sessão por fluxo, e agregado gerenciado pela máquina de estados do protocolo.

Apesar de fim a fim, sinalização intra-domínio, os outros casos que poderão necessitar de sinalização inter-domínio, são tratados da mesma maneira, sendo repassados para o próximo domínio, para tratamento, conforme o agente local. Dependendo da relação entre domínios, o NSIS pode cobrir um único domínio ou múltiplos domínios concatenados. O último caso, pressupõe a existência de relação confiança entre domínios.

A característica da sinalização NSIS é que ela está relacionada a fluxos específicos, e que envolve nós na rede, em vez de correr transparente entre os hosts finais.

O serviço mais simples prestado pelo NSIS é a gestão do controle de estado da rede, a nível de um fluxo específico. Em particular, deverá ser possível controlar atualizações de roteamento, sendo feita outra sinalização para a nova rota, atualizando o estado adequadamente para a nova rota. Contudo, para alguns cenários mais complexos é conveniente atualizar o fluxo, por exemplo modelos de rede utilizando mobilidade. Um novo fluxo pode ser adicionado, e os antigos suprimidos, ou ainda transferir o estado da rede dos fluxos de dados para mantê-lo associado com a mesmo sessão.

%-------------------------------%

% ----------------------------------------------------------------------- %
% Arquivo: nsisgoettingen.tex
% ----------------------------------------------------------------------- %

\section{O protocolo NSIS pela Universidade de Goettingen}
\label{c_cap_nsis_goettingen}

Como avanço de um protocolo de sinalização, com reserva de estados, a IETF criou o grupo de trabalho do NSIS (Next Steps In Signaling). O NSIS fornece um modelo de entidade para redes com controle de sinalização para domínios de rede. O protocolo NSIS é composto em uma camada inferior chamada NTLP (Transport Layer Protocol), e uma camada superior, que é diferente para cada pedido de sinalização, conhecido como NSLP(NSIS Signaling Layer Protocol).

A IETF criou o grupo de trabalho para a criação de normas e definição do protocolo NSIS. Contudo, exitem pelo menos 3 grupos de trabalho que implementam o NSIS, sendo duas implementações em C++ (Universidade de Karlsruhe e Goettingen, ambas na Alemanha) e uma e java (Universidade de Coimbra, Portugal). O protocolo NTLP NSIS desenvolvido pelo grupo de trabalho do NSIS é conhecido como o General Internet Signaling Transport (GIST).

Na Universidade de Goettingen, Alemanha, é feita uma implementação do NSIS, o Free Next Steps In Signaling (FreeNSIS) ou formalmente conhecido como OpenNSIS. Inicialmente conhecido como OpenNSIS, porém alterado por direitos autorais. Tendo como integrantes da implementação Xiaoming Fu, Christian Dickmann, Bernd Schloer, Henning Peters, Ingo Juchem, Niklas Steinleitner, Hannes Tschofenig e Andreas Westermaier, além de contribuidores.

A implementação pela Universidade de Goettingen, atualmente na versão 0.6.0, suporta algumas aplicações que podem ser oferecidas pelo NSIS, como as implementações de GIST, NSLP QoS, NAT / FW NSLP e aplicações para teste de comunicação e reserva. A maioria das aplicações são distribuídas sob a licença GPL. No entanto, a API entre GIST e as NSLPs é liberado sob a licença LGPL.

Dentre os pacotes do NSIS implementado pela universidade de Goettingen, o NSIS-QOSD (Servidor de gerenciamento de QoS), NSIS-QOS (Cliente que faz requisições de QoS), NSIS-PING (análise da rede) e a implementação particular de NAT/FW NSLP.

Basicamente o NSIS funciona de maneira simples. A sinalização de pacotes NSIS não tem conexão direta com os pacotes de dados. Na verdade fala-se de fluxos de dados. Normalmente, um fluxo de dados é identificado pela fonte e IP de destino, protocolo de transporte utilizado, a origem e o destino e talvez algumas outras informações, como o DiffServ CodePoint ou um identificador de fluxo. Todos estes parâmetros são resumidos como informação do fluxo, que é codificado no roteamento, GIST.

O QoS-NSLP é capaz de reservar recursos QoS ao longo do caminho percorrido pelo fluxo de dados. Ele receberá e conhecerá todas as informações de fluxo para NSIS que precisa saber sobre o fluxo de dados. A sinalização invoca o NSIS (QoS-NSLP), que requer um certo grau de qualidade de serviço para um determinado fluxo, passando as informações do fluxo. Então, sem ligação direta com o tráfego de dados, o NSIS faz todo o trabalho de reservar QoS sobre os roteadores no caminho de dados.

As mensagens de sinalização são recuperadas analizando os eventos dos soquetes abertos na sinalização do fluxo. Estas mensagens são então analisadas pelo GIST (GistMessage) e validadas através do ID (identificador de sessao) contido no pacote do fluxo e no GIST. Se não existir a identificação do fluxo associada a um soquete, o fluxo é criado e o sentido da mensagem é determinado.

\subsection{O GIST}
O GIST, ou General Internet Signalling Transport, assume que outros mecanismos são responsáveis pelo controle de roteamento dentro da rede. O GIST é um modelo padrão para a camada de tranporte, que pode ser utilizado com os protocolos de sinalização como o RSVP e NSIS.

A Implementação do GIST por Goetting consiste principalmente em seis partes:
- Principalmente eventos de loop, baseados nos soquetes de conexão;
- Mensagem de estado de roteamento (MRS);
- Associação de mensagem (MA);
- Maquina de estados (FSM - Finite State Machine)
- Mensagem de análise de composição;
- NSLP API 

A sinalização da aplicação requer um conjunto de regras de gerenciamento de estado, bem como protocolo de apoio para a troca de mensagens de dados ao longo do caminho. Vários aspectos deste protocolo de apoio são comuns a todos ou um grande número de pedidos de sinalização e, portanto, pode ser desenvolvido como um protocolo comum.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/gist_layer.png}
 \caption{Modelo estrutura GIST}
 \label{fig:cap_gist_layer}
\end{figure}

Importante ressaltar a API do GIST é uma interface entre a camada de transporte, o próprio GIST e a camada de aplicação. Cabe ressaltar que a camada de transporte é sustentada pela camada de tranporte do modelo da internet, a figura .... mostra isto:

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/gist_layer_osi.png}
 \caption{Modelo camadas GIST}
 \label{fig:cap_gist_layer_osi}
\end{figure}

NTLP é projetado para suportar diversos tipos de aplicações de sinalização, pois sua funcionalidade é independente de uma aplicação específica. O comportamento do NTLP, em funcionamento, é transparente para as camadas de transporte e aplicação, este funcionamento se torna adequado para evitar interferências às mensagens de sinalização.

O  NTLP, em si é um protocolo ponto a ponto. Isto significa que ao longo de um caminho, um nó NTLP só pode receber dados enviados pelos seus pares adjacentes, ainda que estes dados não são destinados a ele. Quando o NTLP recebe uma mensagem de uma sinalização que não for destinado a ele, o NTLP simplesmente encaminha a mensagem para o seu próximo par adjacente, que irá entregá-lo para a camada NSLP adequada. O transporte de uma mensagem de sinalização NSIS depende, portanto, da capacidade de um nó de encontrar ou localizar corretamente seu próximo nó adjacente.

Cada GIST tem uma identificação de sessão, que é única dentro da rede. A camada de transporte diferencia sessões por fluxo que é identificado pelo seu endereço IP fonte, IP destino, número de porta da fonte, o número da porta de destino e protocolo de transporte. Este identificador é associado a aplicação dos fluxos de dados e deve permanecer inalterada durante toda a duração deste fluxo de dados.

\subsection{NAT/FW NSLP}
O NSIS natfw é um exemplo de cliente NAT/Firewall NSLP cuja finalidade é limitada principalmente ao desenvolvimento de testes. A API destina-se a ser incluído em aplicações para falar diretamente com NAT / Firewall NSLP para configurar dispositivos NAT ou firewall ao longo de um caminho. Ele pode ser acionado através do GIST na camada de transporte.
O NAT / Firewall NSLP pode ser acionado para enviar mensagens de vários tipos, dependendo do modelo escolhido, uma série de tipos específicos de opções pode ser definido, como proxy, simulação de processos, bloqueio ou permissao de fluxos de pacotes e regras de policiamento.

\subsection{QoS NSLP}
O principal daemon de aplicação, estabelece e pode manter o estado nos nós, ao longo do caminho de um fluxo de dados com o propósito de fornecer recursos para esse fluxo. O QoS NSLP, como é chamado, invoca o GIST para efetuar tarefas da sinalização de mensagem e utiliza sinalização soft-state para atualizar as mensagens como o principal mecanismo de manutençao de estado.

O NSLP esta na camada de aplicação, suja arquitetura pode ser mostrada na figura \ref{fig:cap_qos_nslp_layer}. Atua na camada acima do GIST, mostrado na figura \ref{fig:cap_gist_layer}, e seu modelo de funcionamento consiste basicamente receber os pacotes de sinalização, processar esta sinalização e passar ao gerenciador de recursos, ou devolver a sinalização ao GIST, para enviar ao outro nó.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/qos_nslp_layer.png}
 \caption{Modelo Estrutura NSLP}
 \label{fig:cap_qos_nslp_layer}
\end{figure}

As mensagens recebidas e capturadas pelo NSLP na entrada do nó e manipulados pelo GIST. Apenas as mensagens relacionadas com QoS são passadas para o QoS NSLP. O GIST também pode gerar triggers ao QoS NSLP, como por exemplo, indícios de mudança de rota. Neste último caso, é feita nova sinalização, para manter a garantia de recursos.

O procolo QOS NSLP trabalha utilziando poucas mensagens de comunicação, sendo basicamente a mensagem de reserva. Mensagens QoS NSLP são enviadas a cada nó da aplicação. Isto significa que um QNE considera seus pares adjacentes como fonte de cada mensagem.

\subsubsection{Tipos de mensagens}
O protocolo QoS NSLP \cite{DRAFTNSLP} utiliza basicamente quatro tipos de mensagens:

\begin{itemize}
 \item RESERVE: A mensagem de reserva é a única mensagem que manipula o estado da reserva do QoS NSLP. É utilizada para criar, atualizar, modificar ou ainda eliminar o estado na entidade. O resultado de uma mensagem de reserva é o mesmo se uma mensagem é recebida uma só vez ou várias vezes.

 \item QUERY: Uma mensagem QUERY é utilizado para solicitar informações sobre o caminho de dados sem fazer uma reserva. As informações obtidas a partir de uma consulta pode ser utilizada no controle de admissão de um processo QNE (por exemplo, no caso de medição baseada em admissão de controle). Esta mensagem não altera as reservas de estado.

 \item RESPONSE: A mensagem de RESPOSTA é utilizada para fornecer informações sobre o resultado de uma mensagem QOS NSLP recebida anteriormente. Isso inclui explicitamente a confirmação do estado na mensagem de reserva, a resposta pode ser uma mensagem QUERY ou uma mensagem de erro se o código QNE ou QNR é incapaz de fornecer as informações solicitadas ou se a resposta é negativa. A mensagem RESPONSE não pode realizar qualquer reserva de estado ou modificação de estado.

\item NOTIFY: são utilizadas para transmitir informações a um QNE. Difere da mensagem RESPONSE na medida que as mensagens são enviadas de modo assíncrono e não precisa de um determinado estado ou mensagem recebida anteriormente. A informação de uma mensagem NOTIFY é normalmente relacionado com as condições de erro.
\end{itemize}

Estas mensagens contém três tipos de objetos, dentro os principais, o QSPEC (QoS Specifications) ou especificação de QoS. O objeto QSPEC \cite{DRAFTQSPEC} transporta informação sobre os recursos necessários, os recursos disponíveis, e outras informações exigidas pelo genreciador de QoS do domínio da rede, por exemplo o RMD.

\begin{enumerate}
 \item Control Information (Informações de Controle): transporta informação para o QoS NSLP, tais como números de sequência, ou quando uma reposta é necessária.
 \item QoS specifications (QSPECs): O objeto QSPEC descreve os recursos que são necessários, dependendo do modelo de QoS a ser utilizado. Também podem conter outras informações utilizadas para controle de um gerenciador de recursos.
 \item Policy objects (Política de objetos): Contêm dados utilizados para autorizar a reserva de recursos.
\end{enumerate}

\subsection{QSPEC}

O QSPEC tem por objetivo prover uma linguagem comum para ser utilizada por gerenciadores de QOS. É adicionado na entrada de um domínio onde o NSIS trabalha e utilizado para sinalizar reservas além das mensagens de RESERVE, QUERY, RESPONSE e NOTIFY.

Um nó QNI inicia uma sinalização e adiciona um objeto QSPEC contendo os parâmetros desejados de QoS. Os parêmtros do QSPEC devem ser interpretados por todos os nós do interior do domínio QNE marcados para gerenciamento de recurso.

Sua estrutura é simples, e fornece uma descrição do tráfego para o qual os recursos são reservados. O cabeçalho do QSPEC pode ser visto na mensagem de sinalização, conforme os cenparios montados:


\begin{verbatim}
\+ Object Type       : InfoSpec
\++ InfoSpec         : 0x01 0x02 0x00 0x00
\+ Object Type       : Qspec
\++ V:Id:M_Seq:OC:l  : 0:0:0:3:20
\+++ QSPEC object    : QoS Desired
\+++ Object type     : Tmod1, length:4
\+++ Object type     : ExcessTreatment, length:1
\+++ QSPEC object    : QoS Available
\+++ Object type     : Tmod1, length:4
\+++ QSPEC object    : Minimum QoS
\+++ Object type     : Tmod1, length:4
(...)
\+++ QSPEC object    : QoS Model (QOSM)
(...)
\+++ QSPEC object    : QoS Reserved
\end{verbatim}

Pode-se descrver os obejtos de QSPEC e sua estrutura conforme abaixo:

\begin{verbatim}
   +---------------------------------------+
   |            QSPEC Objects              |
   +---------------------------------------+

   \________________ ______________________/
                    V
   +----------+----------+---------+-------+
   |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
   +----------+----------+---------+-------+

   \____ ____/\___ _____/\___ ____/\__ ___/
        V         V          V        V

   +-------------+...     +-------------+...
   |QSPEC Para. 1|        |QSPEC Para. n|
   +-------------+...     +-------------+...

\end{verbatim}


\begin{itemize}
 \item QSPEC: QSPEC é o objeto de QoS NSLP contendo todas as informações específicas de QoS.
 \item QoS Available: Objeto QSPEC que contém parâmetros descrevendo os recursos disponíveis. Eles são usados para recolher informação junto de uma reserva.
 \item QoS Desired: Objeto QSPEC que contém parâmetros descrevendo os parâmetros de QoS desejado para os quais o QNI recebeu tráfego.
 \item QoS Model (QOSM): Um método com o modelo de QoS desejado pelos domínios.
 \item QoS Reserved: Objeto QSPEC que contém parâmetros descrevendo os recursos reservados e os respectivos parâmetros de QoS.
 \item QSPEC parameter: Parâmetros utilizados em uma espeficicação, como latência, modelo de tráfego (TMOD) e tratamento.
 \item QSPEC Object: Principais parêmetros de um QSPEC estabelecido tanto na entrada como na saída de um gerenciador de QoS.
 \item QSPEC Type: Identifica um determinado QOSM utilizado no QSPEC.
\end{itemize}

\subsection{Modelo de funcionamento do NSIS de Goettingen}
\label{modelo_funcionamento_goettingen}

A implementação do protocolo de Goettingen foi feita em C++ de maneira modular. O NSIS de Goettingen baseia-se no protocolo GIST que fornece a funcionalidade básica de transporte comum aos protocolos de sinalização. Sua estrutura geral consiste em quatro partes sendo a implementação do GIST, a implementação do NSLP, a implementação da aplicação para usuários e as bibliotecas comuns aos protocolos.

O \textit{framework} de desenvolvimento fornece ainda um modelo para sua própria plataforma de desenvolvimento, além do código fonte livre, sob licença GPL, dentro do diretório do nsis há o subdiretório \textit{skeleton} que contém um modelo do procolo de desenvolvimento do nsis.

O modelo de funcionamento do nsis pode ser descrito através das classes que são instanciadas





falar dos componentes... camadas... API...

